1. The Field of the Invention
The present invention relates to computer network security. More specifically, the present invention relates to systems, methods, and computer program products that substantially decrease the likelihood of an unauthorized process receiving a resource request directed to a Uniform Resource Identifier namespace.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g. information management, scheduling, and word processing) that prior to the advent of the computer system were typically performed manually. More recently, computer systems have been coupled to one another to form computer networks over which computer systems may transfer data electronically.
For the most part, resources are accessed over computer networks using a request/response model. That is, a client computer system (hereinafter referred to as a “client”) sends a request (e.g., to access data, to start a remote application, etc.) across a computer network to a server computer system (hereinafter referred to as a “server”). If the server successfully receives the request and there are no technical impediments to processing the request (e.g., the server does not have access to requested data, network communications are not possible, etc.), the server may respond according to the client's request.
Often, a single server will include the functionality to process a number of different types of resource requests. For example, a single server may process resource requests to access data stored in a variety of different formats (e.g., word processing documents, electronic mail messages, Web pages, etc.) and may process resource requests to execute different remote applications (e.g., word processor applications, database management applications, etc.). Each resource request may need to be processed differently due to the configuration of a particular data type or a particular remote application. Thus, to have a server respond in an appropriate manner, received resource requests must include some indication of the functionality that is desired. As such, clients frequently include such an indication within a request.
One very popular request/response model is that used on the World Wide Web (“WWW”), where a client indicates this desired functionality to a server by sending a Uniform Resource Locator (“URL”). A URL generally takes the form of a character string that conforms to established formats for accessing content on the WWW. One established format dictates that a URL can be of the form http://<hostpart>:<port>/<RelativeURI> (e.g., http:/www.uspto.gov:80/main/patents.htm), where <hostpart> is a proper host name (e.g., a fully qualified domain name), <port> is a numeric string representing a Transmission Control Protocol (“TCP”) port (e.g., 80 for http), and <RelativeURI> is an arbitrary path that indicates a location within the machine represented by the <hostpart>. In operation, a user of a client typically enters a URL into a Web browser and the machine represented by the <hostpart> of the URL responds appropriately.
At the server, different applications can be configured to respond to resource requests having different URLs. For example, the server may configure a Web server application to respond to Web page requests and configure an electronic mail application to respond to electronic mail message requests. In order for an application to respond to a resource request for a particular URL, the request must first be routed to the application. A routing entity at the server can maintain a number of routing entries in a routing table that correlate URLs to applications. Each entry in the routing table can include a routing URL and an application identifier identifying the application that is registered to receive requests for the URL. When a resource request including a particular URL is received, the routing entity identifies the routing entry with a routing URL that most closely matches the particular URL. The routing entity then routes the resource request to the application identified by the application identifier of the routing entry.
Typically, to add an entry to the routing table, an application desirous of receiving requests for a particular URL indicates this desire to the routing entity by requesting to register with the routing entity. If the routing entity determines that no other application is currently registered to receive requests for the particular URL (i.e., no other application has an entry in the routing table), the attempt at registration will be successful. After the successful registration attempt, an entry correlating the particular URL and the registered application is included in the routing table. From that point on, the entry will cause the routing entity to route all requests for the particular URL to the registered application. Further, subsequent registration requests for the particular URL will be denied since the routing entity will determine (by checking the routing table) that an application (the registered application) is currently registered to receive requests for the particular URL.
One problem in current registration schemes is that virtually any application on a server can register to receive requests for virtually any URL managed by the server. The primary requirement that must be satisfied to approve a registration for a URL is that no other application currently be registered to receive requests for the URL. Thus, an unauthorized application (e.g., a virus, a Trojan Horse, an application designed to intercept personal information, etc.) could successfully register for a particular URL simply by requesting to register for the particular URL before any other applications. Further, a successful registration by a unauthorized application essentially “locks out” any legitimate applications (e.g. those an administrator desires to receive requests for the particular URL) that subsequently request to register for the particular URL. When subsequent requests to register for the particular URL are received, the routing entity will determine (e.g., by checking the routing table) that another application (the unauthorized application) has already registered for the particular URL and thus will deny any subsequent requests.
Further, when a resource request for a particular URL is received, the routing entity simply routes the resource request to an identified application from the routing table. No validation is performed to insure that the identified application is indeed a legitimate application. Thus, once a routing table contains an entry correlating the particular URL and the unauthorized application, the unauthorized application can continue to receive resource requests for the particular URL and may never be detected by the routing entity. This can be problematic for users at clients, as these users may have limited technical expertise and little, if any, resources available to determine what application is on the receiving end of a resource request for the particular URL. Thus, a user at a client may unsuspectingly send a resource request with sensitive personal information such as, for example, a credit card or social security number, that is summarily routed to the unauthorized process.
It may take an increased level of technical expertise, such as, for example, that of a system administrator, to identify that a unauthorized process is receiving requests for the particular URL. However, even if an administrator identifies the unauthorized application, the administrator may have no way to dynamically change the configuration of the routing entity and/or the routing table to prevent the unauthorized application from receiving requests for the particular URL. The administrator may be required to completely disable the routing entity or cut off power to the server, thus also disabling other legitimate applications, to prevent the unauthorized application from receiving requests for the particular URI.
Therefore, what are desired are systems, methods, and computer program products, for securing Uniform Resource Identifier namespaces.